As computers become more powerful and the capacity of mass storage devices (e.g. hard drives) rapidly increases, users are able to store an increasing amount of information as well as load numerous applications of varying types onto their computers. With this being the case, often it becomes time-consuming and difficult to efficiently identify, locate and instantiate or launch the various needed applications and information in an efficient, convenient, and timely manner. Further, as is becoming more commonplace, the ability to rapidly identify a sought application on a computer having numerous applications, presents a user with additional challenges. As computer users often run multiple applications during active sessions, the time and effort needed by a user to identify, locate and activate or launch each of those needed applications during the course of their regular activities often distracts, interrupts, and delays a user from accomplishing their primary work task during the session.
Conventional approaches in the field offer a user limited options, each of which only provide a user with further limitations in attempting to overcome the above issues. For instance, conventional approaches are known to include “Adaptive Graphical User Interfaces,” “Context-Based Graphical User Interfaces,” “Application Launching Utilities,” and “Application Grouping Utilities,” each of which is further discussed below.
Adaptive Graphical User Interfaces
It will be understood by those skilled in the art that an Adaptive Graphical User Interface typically adapts a graphical user interface (GUI) in response to what is understood to be the needs of the user in a limited context. In an Adaptive Graphical User Interface, typically icons and menus are manipulated to reflect suggestions for options in the menu, for instance, or may actually modify a menu for a particular user based on the user's experience with a particular feature. For example, an Adaptive Graphical User Interface may be configured to automatically determine and organize selectable elements on a GUI as being those elements which are selected most frequently by a user. In such an example, the selectable elements would be organized on an area of the GUI which could be easily selected by a user for instance. Typically, these conventional designs modify the menu options presented to a user based on prior usage or estimated experience with a feature. In some instances, an option may be suggested for execution or even be configured for automatic execution.
In a further example, Microsoft® Word's simple-to-expandable menu structure is another example of an Adaptive Graphical User Interface approach. In this example, usage by the user typically determines which items are thereafter presented or hidden in the menubar. Additionally, it will be appreciated by those skilled in the art that Adaptive Graphical User Interfaces typically only filter the numerous options available to a user and present a limited set of options, which ideally are only the options the user is considering at that particular moment.
Therefore, as is evident from the Adaptive Graphical User Interface approach, there are very specific limitations to overcome the above issues, including: (1) these types of conventional interfaces are restricted to a specific application and are incapable of grouping sets of applications, for instance, that may be used together by a user when performing a task; (2) the adaptive interface is constructed from a predefined set of interfaces, such that it is not constructed on-the-fly, nor is the user able to create their own customized interface; and, (3) options for the user's interests are not automatically selected nor are such preloaded in preparation for their use by the user.
Context-Based Graphical User Interfaces
It will be understood by those skilled in the art that a Context-Based Graphical User Interface presents an interface based on the context of the current user experience. This context can be based on, for example, the role the user is playing at a particular time or on a particular day (e.g., whether the user is expected to be working or relaxing), or the context may be based on the current location of the user (e.g., whether the user is most likely at home or at work). In certain of these types of interfaces, a set of contexts is first defined, each of which may be associated with one or more user interface (UI) elements that can be used to build a user interface most suitable to that context. It will be appreciated by those skilled in the art that the UI elements typically include such information as user preferences, favorites lists, toolbars, default directories, etc., and each of the UI elements corresponds to one or more of the predefined contexts. In one example, where a user logs into a computer system, a contextual engine residing in the host computer determines the context of the current experience, and provides a user interface built from the UI elements associated with that context to the user.
Therefore, as is evident from the Context-Based Graphical User Interface approach, there are very specific limitations to overcome the above issues, including: (1) there is no automatic creation of a context or dynamic modification of the options that are presented in each context; rather, a predefined interface is presented when a context is detected; and, (2) there is no automatic execution of the programs in a context based on prior use, time of day, etc.
Application Launching Utilities
It will be understood by those skilled in the art that an Application Launching Utility creates program groups that can be launched at a later time in a simpler fashion (e.g., a single mouse click) moreso than launching each program in the program group separately. In such situations, the user is typically responsible for the creation of the group and to determine the contents of the group. Further, once a group is created, it remains static.
Therefore, as is evident from the Application Launching Utility approach, there are very specific limitations to overcome the above issues, including: there is no automatic creation or dynamic modification of groups provided for.
Application Grouping Utilities
It will be understood by those skilled in the art that Application Grouping Utilities typically chain applications together provided those applications work on a common set of data or are otherwise involved in a fixed fashion. For example, a circuit designer may first bring up a schematic editor to design a circuit, then the designer may bring up a simulator to time the design, and finally the designer may bring up a waveform viewer to analyze the timing results. Since these applications pass data from one to the other, an Application Grouping Utility would typically group these three applications together and present them as a single task group on the user interface. In operation, the Application Grouping Utilities found above, for instance, require that the group be created by the user, without automation or influence as to prior use by the user. To create the groups, the user must invoke an “automatic group” request to thereafter group the next applications sequentially invoked by the user.
Therefore, as is evident from the Application Grouping Utilities approach, there are very specific limitations to overcome the above issues, including: (1) there is no automatic creation or dynamic modification of groups based on prior usage; and, (2) the order that the applications are invoked determines how the group is actually created, where a change in order would change how the group is presented.
Accordingly, in view of these conventional approaches which do not address or overcome the above issues, what is needed is a dynamic way to launch multiple applications that is able to be launched based upon a user's needs. Accordingly, a system and method that provides fast, convenient access to applications and information at the most appropriate time for a particular user is needed. The present invention addresses such a need.